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Technical field of the Invention 

The present invention pertains to method and 
apparatus for delivering messages among sites of 
a network of store-and-forward messaging system 
sites using telephone lines. 

Background of the Invention 

There is a need in the art for method and 
apparatus for transmitting audio (voice, fax etc), 
messages, user names —alphabetic and/or spoken, 
and network addresses among sites of a network of 
store-and-forward messaging sites using telephone 
lines. 

Summary of the Invention 

Embodiments of the present invention advanta- 
geously satisfy the above-identified need in the art 
and provide method and apparatus for transmitting 
voice messages, user names --alphabetic and/or 
spoken, and network addresses among sites of a 
network of store-and-forward messaging system 
sites using telephone lines. 

Brief Description of the Drawing 

A complete understanding of the present inven- 
tion may be gained by considering the following 
detailed description in conjunction with the accom- 
panying drawing, in which: 

FIG. 1 is an block diagram of a network of store- 
and-forward messaging system sites; and 
FIG. 2 shows control commands and responses 
exchanged in accordance with the present in- 
vention by two communicating voice store-and- 
forward messaging sites of the network shown in 
FIG. 1. 

Detailed Description 



FIG. 1 shows network 90 which utilizes an 
embodiment of the present invention. For ease of 
understanding, we will first describe some basic 
transactions which are carried out in network 90 
before we describe a preferred embodiment of the 
present invention in detail with reference to FIG. 2. 

Network 90 is comprised of audio (voice) store- 
and-forward messaging system sites 10i to I0 n . 
Each of store-and-forward messaging system sites 
10i to 10 n interacts with local users and is com- 
prised of a local database 20i to 20 n , respectively. 
Further, as is shown in FIG. 1, each of store-and- 
forward messaging system sites 10i to 10 n has a 
communications connection with predetermined 
ones of the other store-and-forward messaging sys- 
tem sites in network 90. Of course, those of or- 



dinary skill in the art clearly appreciate that network 
90 may also be embodied in a manner wherein 
private branch exchanges are utilized so that any 
site may contact any other site via. for example, 
5 the public telephone network. Embodiments of the 
present invention provide the mechanism whereby 
the transactions described below occur. 

In one type of message transfer transaction 
which is carried out over network 90, whenever a 
w message sender at a first store-and-forward mes- 
saging system site addresses a message recipient 
at a second store-and-forward messaging system 
site by name and the message recipient's name is 
not stored in the message sender's local database, 
75 the message sender's local store-and-forward mes- 
saging system site requires the message sender to 
address the message recipient by numeric ad- 
dress. Then, the message sender's local store-and- 
forward messaging system site transmits the mes- 
20 sage, for example, a voice message, to the local 
store-and-forward message system site of the mes- 
sage recipient along with the message sender's 
alphabetic name and a flag which indicates that the 
message recipient's name is unknown to the send- 
25 ing system site. In response, the receiving system 
site sends a communication to the sending system 
site to: (a) request a spoken record of the message 
sender's name if the message recipient's system 
site does not have the message sender's name in 
30 its local database and (b) transmit the message 
recipient's alphabetic and spoken name. Finally, 
both the sender's and recipient's system sites, as 
necessary, update their local databases with the 
sender's and the recipient's alphabetic and spoken 
35 names, respectively. As a result of this, as one can 
readily appreciate, both the sender's and recipi- 
ent's system sites now know the sender's and 
recipient's names and name entry and name con- 
firmation can be used the next time a message is 
40 addressed to the same recipient and name entry 
and name confirmation for the message sender can 
also be used by users of the original message 
recipient's system site. 

In another type of transaction where the mes- 
45 sage sender's system site has the alphabetic name 
of the message recipient in its local database, the 
message sender may address a message recipient 
by either name or telephone number. Then, when 
the message sender's local store-and-forward mes- 
50 sage system transmits a message to the local 
store-and-forward message system site of the mes- 
sage recipient, both the message recipient's al- 
phabetic name and telephone number are transmit- 
ted to the message recipient's system site. In re- 
55 sponse. the message recipient's system site veri- 
fies the message recipient's alphabetic name and 
telephone number and the message may not be 
accepted unless both match. This provides a mea- 
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sure of security in case the recipient is a person 
with the same name as a user who has previously 
left the system. 

We now turn to describe the manner in which 
an embodiment of the present invention operates in 
detail with reference to FIG. 2 to enable the above- 
described transactions to occur. FIG. 2 shows the 
control commands and responses exchanged by 
two communicating audio (voice) store-and-forward 
messaging system sites during a typical session. A 
session is established when site T makes a tele- 
phone call to a reserved access number at site "j". 
The answering site, site "j", knows that this tele- 
phone call is a network call which is being made 
by another voice store-and-forward messaging site, 
site "i". as opposed to, for example, a telephone 
call which is being made by a user, because the 
call is being made to a reserved access telephone 
number. The telephone call may go over public 
switched telephone lines or over private lines. 

We will now describe the communication be- 
tween site "i" and site "j" in general terms. First, 
the communicating sites perform a line test to 
ensure that the quality of the line is adequate for 
the session. If the line passes the test, then the two 
sites connect modems to the line. Although a line 
test is not essential, it is highly recommended, to 
ensure that voice signals which are delivered 
across the network remain of high quality. Those of 
ordinary skill in the art understand that there are 
many methods which are well known to those of 
ordinary skill in the art for performing a line test. 
Second, using the modems, the sites exchange 
control commands and responses in a manner 
which will be described in detail below in connec- 
tion with FIG. 2. Third, at predetermined times 
during a session, the sites "turn-off" the modems 
and the communicating sites exchange voice sig- 
nals over the line. The voice signals may relate to 
a voice message being delivered from one user to 
another or they may relate to a spoken name. After 
the voice signals are transmitted, the sites "turn- 
on" the modems to permit the sites to exchange 
verification of delivery notifications and to move on 
to the next user message or name. Fourth, a ses- 
sion ends when either site, generally the sending 
site hangs up by, for example, going on-hook. The 
other site will disconnect because it will detect the 
remote modem dropping —for example, it detects a 
carrier fault- or because the telephone network 
signals the far end disconnect, whichever occurs 
first. 

The protocol used for communication between 
sites is comprised of four (4) layers. The first or 
bottom layer, i.e., the physical layer is where me- 
chanical, electrical, functional, and procedural char- 
acteristics are defined to access a physical me- 
dium, for example, a telephone line. The next or 



second layer, i.e.. the data link layer, provides for 
reliable transfer of information across the physical 
layer by sending blocks of data, referred to as 
frames, along with synchronization, error control, 

5 and flow control. In addition, the second layer also 
supervises transitions from: (a) line test stage to 
modem; (b) from modem to voice; and (c) voice to 
modem. The first twa-layers are well known to 
those of ordinary skill in the art. 

70 We next describe the third layer, i.e., the ses- 

sion layer, and the fourth layer, i.e., the application 
layer. FIG. 2 shows the control commands and 
responses which reside at the session and applica- 
tion layers. 

/5 The session layer provides a structure for com- 

munication between applications and, as such, it 
establishes, manages, and terminates connections, 
i.e., sessions, between message delivery applica- 
tions. The application layer carries out exchanges 
20 of user messages and names using services pro- 
vided by the bottom layers. 

In particular, as shown in FIG. 2 at line 200, to 
initiate a session layer, sending site "i" generates a 
"Connect command" whenever the bottom layers 
25 notify "it that the link is ready, i.e., receiving site "j" 
has answered, the line test has been performed 
and passed, and the modem is on line. A "Connect 
command" comprises the following information: (a) 
protocol version number used by sending site "i" 
30 so that sites which utilize older versions of the 
protocol can communicate -for example, if the 
protocol version numbers of sending site "i" and 
receiving site "j" are different, the older protocol is 
used; (b) channel number, i.e., port, being used by 
35 sending site "i" for this session -this is needed to 
route received application layer commands and 
responses to the proper process, i.e., the software 
task that is handling this particular session; (c) flag 
to indicate whether sending site "i" will permit 
40 receiving site "j" to turn the connection around 
after sending site "i" has finished sending all its 
voice messages, so that receiving site "j" can 
"piggyback," i.e., send, its own messages during 
the same call -the "piggyback" feature is decided 
45 solely by sending site "i"; (d) flag which indicates 
whether sending site "i" will exchange names with 
receiving site "j" —if one site is willing to exchange, 
but not the other, the latter wins; (e) identification of 
sending site "i"; and (f)- identification of sending 
so node. The byte format for this command is set 
forth in detail in the Appendix. 

As shown in FIG. 2 at line 210, in response to 
the "Connect command," receiving site "j" sends a 
"Connect response" back to site "i". A "Connect 
55 response" comprises the following information: (a) 
protocol version number used by receiving site "j"; 
(b) channel number being used by receiving site 
"j" for this session; (c) flag which indicates whether 
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receiving site "j" will exchange names with sending 
site V; (d) status code which indicates whether 
receiving site "j" W 'H accept the call or a reason 
why it cannot; (e) identification of receiving site "j": 
and (f) identification of receiving node. The byte 
format for this command is set forth in detail in the 
Appendix. 

If a session is established successfully in ac- 
cordance with the above-described "Connect" 
command" and "Connect response" dialogue, then 
the connection settles into "steady-state" mode. In 
this stage, the next set of commands and re- 
sponses shown in Fig. 2 will repeat once for every 
subscriber message that needs to be delivered. 

As shown in FIG. 2 at line 220, the first com- 
mand of a repeating set is a "Record command" 
which is sent from sending site V to receiving site 
"j". The "Record command" comprises the follow- 
ing information: (a) message sender's network ad- 
dress and message recipient's network address; (b) 
message recipient's name if it is available at send- 
ing site "i" -This is sent so that receiving site "j" 
can verify that both the message recipient's net- 
work address and name match a profile of a mes- 
sage recipient. If the message recipient's name or 
the message recipient's network address or both 
do not match a profile stored in a local database 
associated with receiving site "j", receiving site "j" 
will notify sending site "i" accordingly; (c) message 
sender's name if the communicating sites negoti- 
ated during session establishment that user names 
would be exchanged; (d) flag to indicate whether 
spoken names for the message sender and the 
message recipient are available at sending site "i" 
-this is only needed if the communicating sites 
negotiated during session establishment that 
names would be exchanged; (e) date and time 
when the message sender recorded the message; 
(f) size of the recorded message, in seconds; (g) 
flag to indicate whether this is a regular message 
which is received by a message receiver in due 
course, a message which is being forwarded from 
a first message recipient to another message re- 
cipient, a return receipt notification of the receipt of 
a message, a message that is being returned to the 
sending site as undeliverable, or a specially 
marked "name only" message which will be de- 
scribed further below; (h) flag to indicate special 
delivery options reguested by the message sender 
such as, for example: (1) whether this message is 
to be delivered immediately or is to be batched for 
delivery at system administrator configurable times 
of the day, (2) whether this is a private message 
which may not be forwarded by the message re- 
cipient to others, and (3) whether the message 
sender requested a return receipt to be sent when 
the message recipient listens to the message; (i) 
identification code which is unique for each mes- 



sage -this is used to detect duplicate delivery of 
the same message and is needed, for example, in 
instances where a receiving site delivers a mes- 
sage to a message recipient, but the connection is 

5 abnormally dropped before the sending site has 
been notified of the successful delivery; and (j) 
identification code which is unique to each re- 
corded voice file stored at the sending site, -this is 
used in instances where the same recording is 

w used by more than one message such as, for 
example, when a message sender addresses the 
same message to multiple message recipients so 
that the voice portion need only be transmitted 
once. The byte format for this command is set forth 

15 in detail in the Appendix. 

As shown in FIG. 2 at line 230, in response to 
the "Record command," receiving site "j" sends 
back a "Record response" which comprises the 
following information: (a) status code, indicating 

20 whether receiving site "j" will accept the message 
or the reason why it cannot. Some possible rea- 
sons for not accepting the message are: (i) the 
message recipient is not valid one, (ii) the message 
recipient's mailbox is full, and (iii) so forth; (b) a 

25 flag indicating whether the message sender's name 
was added to the database at receiving site "j"; (c) 
a flag indicating whether receiving site "j" wishes 
to receive the spoken name of the message sender 
and whether it intends to send the spoken name of 

30 the message recipient; (d) name of the message 
recipient, if sending site "i" did not include it in the 
"Record command" because sending site "i" did 
not have it and the communicating sites negotiated 
during session establishment that user names 

35 would be exchanged. The byte format for this com- 
mand is set forth in detail in the Appendix. 

The next step in the communication depends 
on the particular "Record command" and "Record 
response" exchanged in a particular case. For ex- 

40 ample, line 240 of FIG. 2 shows a portion of a 
communication wherein the next step comprises 
sending site T transmitting the message sender's 
spoken name to receiving site "j". This transmittal 
is accomplished when site "i" and site "j" switch 

45 off their modems and, then, sending site "i" trans- 
mits the message sender's spoken name while 
receiving site "j" receives and records it. Once the 
recording is completed, site w i" and site "j" switch 
their modems back on so that receiving site "j" 

so may acknowledge successful or non-successful re- 
ception. As shown at tine 250 of FIG. 2, this is 
done when receiving site "j" transmits a "Stop 
response" to sending site "T, which "Stop re- 
sponse" comprises a status code. The byte format 

55 for this command is set forth in detail in the Appen- 
dix. The reason this is considered a response is 
because the command to stop recording is impli- 
citly generated by sending site "i" when it stops 
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playback and switches its modem on. thereby 
causing receiving site "j" to turn its modem on too. 
If it is appropriate for the communicating sites to 
skip transmission of the spoken name for the mes- 
sage sender, they just simply eliminate the two 
steps above in the sequence. 

Site "i" and site "j" may decide, based on the 
"Record command" and "Record response" sent 
previously, to transmit the spoken name for the 
message recipient. To do that, they just repeat the 
two steps outlined above, reversing roles, as shown 
by lines 260 and 270 of FIG. 2. If this is not 
appropriate, these steps are skipped. 

Finally, as shown by lines 280 and 290 of FIG. 
2, a voice message is transmitted in a manner 
which is similar to the manner in which the spoken 
names were transmitted. Note that these steps may 
also be skipped. This would occur, for example, in 
cases such as: (a) delivery of a "return receipt" 
-which "return receipt" has no associated voice 
message; (b) delivery of a message for which 
receiving site "j" already has the recording; or (c) 
duplicate delivery of a previously sent message. 

In accordance with the present invention, a 
variation of the above-described repeating set of 
commands and responses is used whenever send- 
ing site V wishes to "export" a selected list of 
subscriber names, alphabetic and spoken, to re- 
ceiving site "j". In this event, since the subscriber 
names being sent are not associated with a voice 
message being delivered, the "Record command" 
specifies that this is a "name only" message- 
Then, only a "Record command", "Record re- 
sponse", optionally the message sender's spoken 
name, and "Stop response" are exchanged. 

After sending site "i" has finished delivering 
everything it intended to deliver, control of the 
connection reverts back to the session layer. At 
this point, sending site "i" has two options. First, it 
goes on-hook, i.e., "hangs up", to signal the end of 
the call or, second, it sends a "Piggyback com- 
mand" having no parameters. The byte format for 
this command is set forth in detail in the Appendix. 
If sending site "i" sends a "Piggyback command", 
then receiving site "j" determines whether it has 
any messages to deliver to sending site "i". If it 
does, receiving site "j" responds by transmitting a 
"Connect command" to initiate a session from the 
beginning, except with roles reversed and in the 
opposite direction. Otherwise, receiving site "j" re- 
sponds to the "Piggyback command" by going on- 
hook. 

In a preferred embodiment of the present in- 
vention, a digital signal processor (DSP) is used to 
provide the above-described functions which relate 
to a modem. This is advantageous in a messaging 
system such as the ROLM Systems PhoneMail 
messaging system because any channel, i.e.. port, 



may be used for network message delivery and 
dedicated ports are not needed. In fact, the same 
board used in PhoneMail for voice processing us- 
ing DSP techniques provides modem emulation 
5 and line test functions used at the beginning of a 
network message delivery session, i.e.. the same 
hardware is used to run the DSP code needed for 
voice processing, modem emulation, and line test- 
ing. This permits one to utilize any port for intersite 
jo message delivery. For example, in a preferred em- 
bodiment of the present invention, a DSP may 
perform the following functions: originate modem, 
answer modem, originate line test, and answer line 
test. Further, it should be clear to those of ordinary 
75 skill in the art as to how these functions may be 
emulated by a DSP. This may be performed as 
follows. First, a sending site would command its 
DSP subsystem to start emulating an originate 
modem on the channel being used for a particular 
20 connection. The recipient site commands its DSP 
subsystem to emulate an answer modem. For ex- 
ample, both DSP subsystems might emulate a Bell 
System 103 modem. Once the respective DSP 
subsystems report "carrier detect," the above-de- 
25 scribed data exchange takes place. Of course, 
those of ordinary skill in the art recognize that, just 
as with a standalone modem, it is possible to get a 
"carrier fault" at any time during the connection 
which would cause the connection to be dropped. 
30 As has been described above, transitions occur 

from "modem" mode to "voice 
playback/recording" mode and then back to 
"modem" mode. This occurs as follows. First, re- 
ceiving site rt j w drops its carrier, i.e., stops sending 
35 the carrier tone. Second, sending site V detects a 
carrier fault, stops its own modem, and starts play- 
ing back a voice message. Third, receiving site "j" 
starts recording as soon as it detects that the 
carrier from sending site "i" has dropped. Fourth, 
40 as receiving site "j" is recording, it constantly mon- 
itors the incoming voice signal to detect the end 
thereof and the beginning of a modem carrier. 
Fifth, whenever sending site V reaches the end of 
the voice message, it turns on its answer modem, 
45 i.e., it puts carrier on the line. Lastly, receiving site 
"j" stops recording and starts its own originate 
modem. 

Those skilled in the art recognize that further 
embodiments of the present invention may be 

so made without departing from its teachings. For 
example, embodiments of the present invention 
may be fabricated utilizing a stand-alone, off-the- 
shelf modem along with hardware needed to switch 
it in and out of the line, the fabrication of which 

55 hardware is well known to those of ordinary skill in 
the art, so that voice can be sent over the same 
line. Further, embodiments of the present invention 
may be fabricated utilizing a stand-alone, off-the- 
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shelf modem and wherein parallel calls are made 
from sending site to receiving site. In one such 
embodiment, one call will carry the voice signals 
and the other call will carry data transmission, i.e.. 
commands and responses, using the modem. Still 
further, embodiments of the present invention may 
be fabricated utilizing DTMF tone generators and 
detectors for sending commands and responses as 
an alternative to the use of modems or modem 
emulators. Yet still further, embodiments of the 
present invention may be fabricated utilizing an 
alternative protocol such as, for example, wherein 
the message sender's spoken name and voice 
message are sent in one transmission, but sepa- 
rated by a predetermined tone. 



sponse to the sending site. 

5. The method of -tiaim 3 wherein the step of 
exchanging predetermined delivery information 

5 comprises the steps of: 

the sending site transmitting a stop re- 
sponse to the receiving site. 

6. The method of claim 4 wherein the step of 
w exchanging predetermined delivery information 

further comprises the steps of: 

the receiving site transmitting a piggyback 
command to the sending site. 

75 



Claims 



1. Method for use in a network of sites for use in 
transmitting messages and audio signals be- 20 
tween two sites which are connected by one or 
more telephone lines, the method comprising 

the steps of: 

exchanging predetermined control com- 
mands and responses using data transmission 25 
and reception apparatus at the two sites, a 
sending site and a receiving site; 

transmitting audio signals between the 
sending and receiving sites using voice trans- 
mission and reception apparatus at the two 30 
sites; and 

exchanging predetermined delivery infor- 
mation using the data transmission and recep- 
tion apparatus at the two sites. 

35 

2. The method of claim 1 wherein the step of 
exchanging predetermined control commands 
and responses comprises the steps of: 

the sending site transmitting a connect 
command to the receiving site and, in re- 40 
sponse; 

the receiving site transmitting a connect 
response to the sending site. 

3. The method of claim 2 wherein the step of 45 
exchanging predetermined control commands 

and responses further comprises: 

the sending site transmitting a record com- 
mand to the receiving site after the sending 
site receives the connect response from the 50 
receiving site and, in response; 

the receiving site transmitting a record re- 
sponse to the sending site. 

4. The method of claim 3 wherein the step of 55 
exchanging predetermined delivery information 
comprises the steps of: 

the receiving site transmitting a stop re- 
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